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(54) Digital code interpreter 

($7) An apparatus lor processing digital audiovis- 
ual data, in particular a decoder far a digital television 
system, comprising one or more hardware devices for 
transmission and reception of data external of trie appa- 
ratus* the apparatus further comprising a data process- 
ing system including a first virtual machine adapted to, 
inter alia, receive code written in an interpretative lan- 
guage downloaded via one or more of the hardware 



devices, said virtual machine being adapted to distin- 
guish between code written in at least two interpretative 
languages in dependence on the structure or the 
received code and to pass such code to a correspond- 
ing interpreter 4278. 4279 means for interpretation and 
execution with reference to a common or specific func- 
tion library 4580, 4530. 
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Description 

[OOOI] The present invention relates Id an apparatus 
for processing cfigftal audio-visual data, in particular a 
decoder for a digital television system including an inter- 
preter: 

[0002] A software based system far controlling a 
decoder in a digital television system that uses avirtual 
machine and run time engine for processing digital tele- 
vision data and downloaded appBcafions is described in 
the POT sppicatton PCT7EP9?y02ll6. This system 
possesses a number of advantages in comparison with 
previously known systems for receiver/decoders, nota- 
bly in regard to the Independence of the appHcation lay- 
ers of the system to the hardware elements of the 
manufectured decoder firough the use of a virtual 
machine structure. 

[0003] Although the use of me virtual machine and 
run-time engine permits the system described in this 
application to be largely independent of the hardware 
level of the system, the openness of the system is nev- 
ertheless nrrwted by the code used to writ© the applica- 
tions which sit on top of the virtual machine level in the 
system As deserted in the application, code is written 
in en interpretative language, which is downloaded into 
the receiver from a broadcast centre and interpreted by 
an interpreter in the virtual machine. 
[M041 Although the code can be chosen to be a com- 
mercially known and standardised language, problems 
can arise, for example where the receiver has to proc- 
ess applications written in two or more different codes. 
This problem can arise, for example, where the decoder 
is introduced in a broadcast system in which the existing 
decoders in the field are adapted to receive applications 
written in code different from that used in the present 
decoder. In such a case, the operator may be obliged to 
download a given application twice: once as written in 
the original language forthe existing decoders and once 
as written in the new code for the new decoders. As will 
be clear, such an operation is relatively inefficient in 
terms of the use of bandwidth. 
[00051 It is an object of the present invention to over- 
come the problems of the prior art system. 
[0006] According to the present invention, there Is pro- 
vided an apparatus for processing digital audio-visual 
rfflia comprising one or more hardware devices for 
transmission and reception of data external of the appa- 
ratus, the apparatus further comprising a data process- 
ing system inducing a first virtual machine adapted fox 
inter a&a receive code written in art interpretative lan- 
guage downloaded via one or more of the hardware 
devices, said virtual machine being adapted to distin- 
guish between code written in at least two interpretative 
languages in dependence on the structure of the 
received code and to pass such code to a correspond- 
ing interpreter means for interpretation and execution. 
[00O7] By providing a virtual machine adapted to dis- 
tinguish between received code together with a plurality 
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ot interpreter means tor interpreting such coda, the 
present invention avoids the problems associated with 
the prior art systems and enables the machine to proc- 
ess instructions arriving in different interpretative lan- 
guages. A fully open system, both in relation to the 
upper appication and lower hardware interfaces may 
thus be provided. 

mrjoS] In one embedment the virtual machine distin- 
guishes between interpretative code h at least two 
interpre&tive languages based an the characteristics of 
a header message associated with a module of code in 
one of the languages, in particular, the virtual machine 
may distinguish between Interpretative code based on 
the presence or Asence of a header message associ- 
ated with a module of code in one of the languages. 
Other embodiments can be imagined, where the 
machine distinguishes between code on the basis of a 
"flag" or other code element in or at the end of a stream 
of transmitted code or on the file name of a module of 
code. 

[00091 The present invention is particularly applicable 
to the s&uation in which one or mare of the interpretative 
languages corresponds to an object oriented language. 
In such an example, the machine may examine tor the 
presence of a header message associated with a class 
file in that language. 

[OOio] in order to implement the code, each inter- 
preter means may execute code with reference to one 
or more function libraries. Preferably, a common func- 
tion library is shared by a plurality of the interpreter 
means, in order to reduce the amount of memory 
needed for the function libraries. 
[0011] Notwithstanding the presence of a common 
function library, one or more of the interpreter means 
may execute code with reference to a function Horary 
exclusive to that interpreter. This may be desirable, for 
example, where certain specialised functions are more 
easily executed by reference to a dedicated function 
itorary. As will be understood, the size of the system 
may be reduced by using function libraries common to 
both virtual machines, wherever possible and/or con- 
venient 

[0012] Whilst fre present invention is particularly 
applicable to a decoder tor receiving and processing 
digital television systems, it will be understood that the 
principles of the data processing system set out m this 
application may also be applied to other devices for 
handling digital audio-visual data such as digital video 
recorders and the &ke» 

[001 S] In the context of a decoder for a digital televi- 
sion broadcast the hardware devices of the decoder 
can include an MPEG demultiplexer together with a 
tuner, a serial interface, a parallel interface, a modem 
and one or more smart card readers. 
[0014] In the present application, the term "decoder* 
is used to apply to an integrated receiver/decoder for 
receiving and decrypting an encoded broadcast the . 
receiver and decoder elements of such a system as 
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considered separately, as wen as to a digital television 
receiver for receiving non-encrypted broadcasts. 
[0015] There will now be described, by way of exam- 
ple only, an embodiment of the present invention, wfth 
reference to the attached fi gures* in which: 

Rgurel src^ancveraflviewof acfi^talteleN«3on 
system; 

Rgure 2 shows the elements of an interarthre sys- 
tem within the digital telariston system of Figure 1 ; 

Figure 3 shows the architecture of me software 
based system implemented . within the 
receiver/decoder of the present invention; 

Figure 4 shows the architecture of me virtual 
machine within the system of Rgure 3, including in 
particular an event manager package* an Interpre- 
tation package and a memory package; 

Figure 5 shows the structure of the interpreter used 
in the virtual machine; 

Figure 6 shows the thread handling within the vir- 
tual machine: 

Rgure 7 shows the operation of the event manager 
and scheduler of the virtual machine; 

Figure 8 shows the management of the memory 
pool by the virtual machine. 



the end user and connected to the end users television 
set 2022. the receiver/decoder 2020 decodes the com- 
pressed MPEG-2 signal into a television signal for the 
television set 2022, 

s [001 51 A ccfictitional access system 3000 is connected 
to the rtnjftpksceraKM and the receiver/decoder 2020, 
and is located partly in the broadcast centre and party 
in the decoder, \\ enables the end user to access digital 
television broadcasts from one or more broadcast sup* 
to pBers. A smartcard, capable of deciphering messages 
relating to cprrtnTercial ofie/s (that is, one or several tel- 
evision programmes sold by the broadcast supplier)* 
can be inserted into the receiver/decoder 2020. Using 
the decoder 2020 and sma rtc ar d. the end user may pur- 
rs chase commercial offers in either a subscription mode 
or a pay-per-view mode 

INTERACTIVE SYSTEM WITHIN THE PfGrrAL TELE- 
VISION! Network 

20 

10019] An irrteracfive system 4000, also connected to 
the rnuJtipIaxer 2004 and the recervetttecodar 2020 and 
again located partly in the broadcast centre and party 
in the decoder, enables the end user to interact with var- 
ss ious applications via a modemmed back channel 4002. 
[0020] Figure 2 shows elements of the general archi- 
tecture of the interactive television system 4000 com- 
prising in overview lour main elements: 

ao 1 . An authoring tool 4004 at the broadcast centre or 
elsewhere for enabling a broadcast suppfier to cre- 
ate, develop, debug and test ^jplicafions. 



DIGITAL TELEVISION NETWORK 

SS 

[001 SI An overview of a tfgital television system 1000 
according to the present invention is shown in Figure 1. 
The invention includes a mostly conventional digital tel- 
evision system 2000 that uses the Known mpeG-2 com- 
pression system 10 transmit compressed digital signals. 40 
In more detail MPEG-2 compressor 2002 in a broad- 
cast centre receives a digfeU signal stream (typically a 
stream of video signals). The compressor 2002 Es con- 
nected to a multiplexer and scrambler 2004 by linkage 
200a 45 
[0017] The multiplexer 2004 receives a plurality of fur- 
ther input signals, assembles one or more transport 
streams and transmits compressed digital signals to a 
transmitter 2003 of the broadcast centre via inkage 
2010, which can of course take a wide variety of forms so 
induding teJecCtfttntmieations links. The transmitter 
2008 transmits electromagnetic signals via uplink 2012 
towards a satellite transponder 2014» where they are 
electronically processed and broadcast via notional 
downlink 2016 to earth receiver 201 8. converrtiorraDy in ss 
the form of a dish owned or rented by the end user. The 
signals received by receiver 2018 are transmitted to an 
integrated receiver/decoder 2020 owned or rented by 



2. An application and data server 4006. at the 
broadcast centre, connected to the authoring tool 

* 4004 for enabling a broadcast supplier to prepare, 
authenticate and format applications and data for 
defivery to the multiplexer and scrambler 2004 for 
insertion into the MPEG-2 transport stream (typi- 
cally the private section thereof) to be broadcast to 
the end user 

3. A data processing system 4008 at the 
receiver/decoder for receiving and processing 
downloaded applications and data and for manag- 
ing communication with the other elements of the 
interactive system and the hardware elements of 
the receiver/decoder, the system 4008 including a 
virtual machine wfth a run time engine (RTE) imple- 
mented as executable code installed in the 
receh/er/decodef. 

4. A modemmed back channel 4002 between the 
receiver/decoder 2020 and the application and data 
server 4006 to communicate signals instructing the 
server 4006 to insert data and applications into the 
MPEG-2 transport stream at the request of the end 
user, Information may also be passed in the other 
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direction. 

[QQ21] The receiver/decoder 2020 includes a number 
of devices for communicating with exterior devices 
within fhe interactive system, such as an tuner for tuning 
the receiver, an MPEG demultiplexer for demultiplexing 
the MPEG signal, a serai interface, a parallel interface, 
a modem and one or two card readers ad^rtedto read, 
for example, credit cards or subscription smart cards 
issued with the system. The characteristics of such 
devices are well known in the field of digital television 
systems and war not be described here in any more 
detaH. 

[0022] Similarly, the sorts of Interactive applications 
that may be provided (home banking, teleshopping. 
downloading of computer software) will be apparent to 
those in the field and will not be described in more 
detail. WhBe the decoder system architecture described 
below ia particularly apt for interactive applications ft will 
also be appreciated that the architecture described can 
be used In simpler non-Interactive digital TV systems, 
such as a conventional pay TV system. 



DECODER SYSTEM ARCH ITECTURE 

{00231 Tuning now to the architecture of the system 
within the receiver/decoder shown in Figure 3. it will be 
seen that a layered architecture is used. The first layer 
4100 represents tie operating system of tie hardware 
of the receiver&ecoder. This is a real-time operating 
system chosen by the manufacturer to control the hard- 
ware elements d the receiver/decoder. The reaMme 
operating system has a relatively fest response time in 
orderto be able to correctly syrtchronise hardware oper- 
ations. Event messages are passed between this layer 
and the middleware layer 4200 immediately above. 
[0Q24] The data processing system 4008 sits on top of 
the hardware operating system and comprises a mid- 
dleware layer and an application (or more correctly an 
application interface) layer. 

[00251 The middleware layer Es written In a language 
such as C ANSI and comprises the elements of a virtual 
machine 4250 and a number of Interfaces 4260 includ- 
ing a graphical interface 4261, a FLASH/PROM mem- 
ory interface 4262, a protocol interface 4263 and a 
device intenace 4264. 

[0026] As with the System set out in patent app&cation 
PCT/EP97/0211 6 descried in more debit in the intro- 
duction, the present invention uses a virtual machine in 
order to provide Independence between upper level 
abdications and the lower level operating system imple- 
mented by the rrtanirfacturer. 

[0027] The interfaces 4260 provide the link between 
operations of the virtual machine and the tower level 
operating system 4100 and also include a number of 
intermediate level application modules more easily exe- 
cuted at this level. 

[0028] The application interface (API) layer 4300 com- 



prises a number of high level packages 431 0-431 4, writ- 
ten in an object-oriented in te r pre t ati ve language, such 
as Java. These packages provide an intenace between 
the applications created by the service provider (inter- 

s active program guide, teleshopping. internet browser 
etc) and the virtual macnineof the system. Examples of 
such applications are given below. 
[0029] The lower level OS is normally embedded in 
the hardware components of the decoder, although in 

10 some realisations, the tower level OS can be down- 
loaded. The middleware and appficafion interlace layer 
packages can be downloaded into the RAM or FLASH 
memory of the decoder tram a broadcast transmission. 
Alternatively, some or all of the middleware or appltea- 

13 tion interface layer elements can be stored In the ROM 
or (if present) FLASH memory of the decoder. As will be 
understood, the physical organisation of the memory 
elements of the decoder is distinct from the logical 
organisation of the memory, 

APP1 ICATTON INTERFACE LAYER 

moan] Referring to the application interface layer 4300 
shown in Figure 3. and as described above, the pack- 
2$ ages in this layer are written in an object oriented lan- 
guage such as Java. Each package defines a set of 
class libraries called on during operation of the system. 
In the present system tie fotf owing packages are 
installed. 

so [0031] Lang/Util Package 4310. These packages 
define the classes necessary for the manipulation of 
objects by the virtual machine. These class Bbraries 
normally form part of a standard library associated with 
the object oriented language chosen. 
$5 [0032] MHEG-5 Pactage 431 1 . This package defines 
the classes associated with the manipulation of graphi- 
cal objects on the television display. Such objects are 
distinct tram auolo-visual data and can make up* for 
example, channel identifiers or text laid over dfcpiayed 
40 rmages. The definition of classes within this package 
should respect the MHEG-6 norms defined by the 
standards ETS 300777-3 and ISO/lSE 13522-5 (and 
the standard fSO/lSE 13522-6 in the case of a Java 
implemented system). 
45 [0033] Toolbox Package 431 2. This package contains 
the classes used for downloading and decompression 
of information as wen as the classes associated with the 
management of the file system and memory within the 
receiver/decoder and the classes associated with the 
so connection to the internet etc 

[0034] Device Package 4313. This package defines 
the classes necessary for management of peripherals 
attached to the receiver/decoder, as discussed above 
and Including the modem, the smart card readers, the 
55 MPEG flow tuner etc 

[0035] Service Package 4314. This package defines 
the classes necessary for the implementation of devel- 
oping higher level interactive applications, such as man- 
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agement of credit card data etc 

[003$] DSMCC-UU Package 431 S. This package 

implements the protocols necessary for communication 

between acfient and a server tor data file search and 

reading, imptemenlaticn of this package should respect 

the norm ISO/IEC 1381 8-6 and directives defined in 

DAVICparta 

100371 A further layer of interactive applications, writ- 
ten by the service provider and downloaded during 
broadcast as in conventional systems, will be laid over 
the interface packages defined above Depending on 
the applications to be Introduced, some of the above 
packages may be omitted, For example, tf the service 
provider does not intend to provide a common way for 
data reading, the DSMCC-UU package may be left out 
of the final system. 

[00381 The pactages4300 provide dass Ovaries far 
an object-oriented programming environment Their 
class behaviour wifl depend on the language chosen. In 
the case of a Java application, for example, a single 
irtheritanca dass structure win be adhered to. 

IMTCPPACg CATER 

[0039] As shown, the interface layer is composed of 
four modules, a graphics module 4261. a memory file 
management module 4261, a protocol module 4263 
and a device manager 4264. Whilst the modules at this 
level are described as interface modules their function is 
to provide a "glue* layer for the implementation of the 
appOca&on interface packages and for the operation of 
the virtual machine generally. 
[00401 The graphics modure 4261. for example, pro- 
vides the creation and management of graphical 
objects. H asks the low level OS to display basic graphic 
shapes such as single pixels, lines, rectangles etc. The 
irrtf ernentation of this module depends on the graphics 
capability of the low level manufacturer's OS* In some 
ways complementary to the MHEG-5 package 4311, 
these functions may be more efficiently executed at this 
code level than in the high level code chosen for the 
application layer above. 

[0041] tn a simiar manner, the memory file manage- 
ment module 4262 Includes low level read/write fie 
commands associated with the memory components of 
the system. Typically, the hardware operating system 
ordy includes comroncfe necessary to read/write a sec- 
tor or page wBhin a memory component As with the 
graphics module 4261, this module enables a set of 
simpler lower fevel applications to be efficiently intro- 
duced in the system 

£0042] The protocol management module 426a 
defines a library of comrnunfcation protocols that may 
be called upon In communications via. for example, the 
TCP/IP layer of the decoder. 

[0042] The device manager 4264 is slightly different 
from the other modules in this layer in that it provides 
the link or interface between the hardware operating 



system and the layers above, nctudtng the other mod- 
ules in the interface layer and the virtual machine. Com- 
mands or event messages that are received/sent to the 
hardware OS from the virtual machine, for example, are 
5 necessarily passed by the device manager lor conver- 
sion accord in g to the interface specifications between 
the two levels. 



VIRTUAL MACHINE DESCRIPTION 
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10044] Referring now to Figure 4. the structure of the 
virtual machine 4250 used in the system of the present 
invention wil be described. The virtual machine used in 
the present invention is a pre-emptive murtithread type 

is machine. The general characteristics of such a machine 
are known in other contexts outside of the audiovisual 
and digital television fields and the following description 
win focus on those areas that are the most specific to 
the present application. 

& [0045] The virtual machine is composed of a rtumber 
of elements; which interact broadly as shown in Figure 
4. 

[0046] The scheduler 4270 composed of a thread 
manager service 4271 and a monitor manager service 

.23 4272 forms the heart of the murtitrtread machine. The 
scheduler 4270 orders the execution of threads created 
by applications externally of the virtual machine and 
those created by the virtual rnachine itself (eg. a gar- 
bage coMection thread as discussed below). 

so [0047] The event manager 4273 handles an event 
routing table and the lists of events subscribed to by the 
threads and centralises the dispatch of event treat- 
ments. 

100451 The memory manager 4274 handles the alo- 
3s cation and disaJ location of the memory zones within the 
system memory and also handles the removal from the 
memory of norKOferenced objects (garbage collection). 
[00491 The dass manager 4275 charges the classes 
of the application code downloaded in a broadcast sig- 
40 nat, interacting with the security manager 4280 to check 
the integrity of downloaded code and with the file man- 
ager 4276, which implements the appScations. 
[0050] Trie file manager 4276 carries out the imple- 
mentation of the system files and me handles the mech- 
45 anism of downloading of interactive applications and 



[0051] The security manager 4280 handles the revel 
of access permitted to downloaded applications, some 
appfcations having the ability to carry out more opera- 

so tions than others in relation to the file system. 

[0052] The interpreter 4277 comprising a bytecode 
interpretation service 4278 and a 'Yn-code" interpreta- 
tion service 4279 handles the interpretation of applica- 
tions written in these two codes, bytecode being 

ss associated with Java applications and m-code being the 
name given to a proprietary code developed by the 
applicants. As wfll be discussed, further interpretation 
services can be added if desired. 
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mo53) The operation and implementation of the class 
manager, file manager and security manager may be 
conventional. "The description wiU now focus on the 
operation of the interpreter, the scheduler and event 
manager and the memory manager, 5 

jNTEBf RETEB 

[0054] Referring now to Figure 5, the operation of the 
interpreter 4277 used in the embodiment of the present 10 
invention win now be deserted. As <fiscussed in the 
introduction, the disadvantage of converrtronal operat- 
ing systems used in decoders imposed to date has 
been their reliance on a single type of code for the high 
level appTtcatibns. Atthough the code chosen may be a is 
cojnr mtr c ia Py avaltabte and widely Known application 
code, problems can nevertheless arise in the case 
wherertisnec^sarytomaintainafieWofa number of 
decoders using different applications written in a 
rruiTiberofc^e^Theirrtei^ so 
perniits toe interpretation of a 

[00551 As shown, files arriving in the system, whether 
bytecode classes or m-code modules are evaluated by 
the module class manager 4500 according to the struc- 
ture of the file, such that the application code delivered 2S 
to tite interpreter 451 o has an indication of format In the 
case of a bytecode appficatforv for exainple. the down- 
loaded class file wSU have a characteristic identification 
header of 4 octets followed by a version number, also of 
4 octets. The interpreter may distinguish between the so 
codes on the basis of the presence or absence of this 
bytecode header- 

[0056] In other embodiments, other characteristics of 
the code types may be used to distingue 
number of app&cation languages, such as the file name. 35 
for example* 

[0057] Depending on the result of trie format indicator, 
bytecode instructions areiSent to the bytecode inter- 
preter 4278. wh ere they are executed wrtfi refer ertce to 
a function library 4520 associated with the byte code <o 
tnstnjcttons, as is conventtonafly the case with intern 
tafive code instructions. The function library of native 
code instructions is defined within the virtual machine, 
10058] In the case of m-code instructions, these are 
passed to a made interpreter 42m The majority of the 
m-code instructions may be implemented and executed 
with reference to the function Ibrary 4520 associated 
wrth byte-code instructions, and the interpreter 4278 
cans on the library 4520 to execute such m-code funo 
tions wherever possible. 50 
[0059] In some circumstances, however, some m- 
code instruceons may need specific execution functions 
not easily etecutafcte with reference to a common func- 
tion library. In such cases, it may be envisaged that the 
instructions be irrptemented with reference to a sepa- ss 
rate function library 4530. 



RCHEOULFR AND EVENT MANAGER 

[0060] The operation of the scheduler 4270 and event 
manager 4273 wffl now be discussed, with reference to 
Figure 6 which shows the lite of a thread within the sys- 
tem and Figure 7 which shows the notification of an 
event to a tivead by the system in response to an event 
signalled by the lower level run-time operating system, 
[0061] The description will concentrate on the han- 
dting of the creation of a thread which represents an 
execution context in particular resulting from a signalled 
event It win be understood that a thread may be created 
with the inflation of a command generated by a higher 
level application to be sent to the hardware OS and by 
the return of this cornmand. A thread may also be cre- 
ated within the virtual machine rteeff, eg a garbage col- 
lection thread. 

[0062] As mentioned above, the present eirtoodiment 
relies on a pre-emptive thread handing virtual machine 
such as that found in Java based systems. In such a 
machine, a plurality of threads are generated and stored 
in a thread queue. The scheduler inspects the thread 
queue and selects the thread with the highest priority to 
be executed Kkymally the thread that ts being executed 
has me highest priority, but such a thread may be inter- 
rupted by a thread of yet a higher priority, as is conven- 
tional in pre-emptive threaded systems In such a case, 
the state of the interrupted thread is stored and the 
thread re-activated once it reselectedto be executed. 
[0063] In certain cases, a thread may itself include a 
so-called "yield" Instruction which causes the scheduler 
to suspend the execution of the thread and to inspect 
the thread queue for any other threads to execute. The 
yield instruction may be present in low priority internally 
generated tasks, such as a garbage collection function 
carried out by the system rn order to remove unused 
objects from the memory of the system. 
[0054] These aspects of the system are shown in Fig- 
ure 6, The creation of a thread at 4550 gives rise to a 
thread stored in the thread queue 4551 . The newly cre- 
ated thread has the state TniT at 4552. If no other 
thread has higher priority, the thread is executed by the 
instruction startfj and will have the state "executable- at 
4558. If the instruction stopQ is executed in the thread, 
the thread becomes 'dead" at 4554. The thread may 
equally achieve this state if completed as incScated by 
the runOfirti instruction. If a yiekfO instruction in the 
thread itself arises, or a suspendO instruction external 
of fre thread is executed, the thread is suspended and 
given the state ^non-executable' at 4556. 
mo€5] Referring now to Figure 7, the interaction 
between th» lower level operating system 4100. the 
event manager 4273 and the scheduler 4270 wffl now 
be described. Raw events signalled by the run-time 
operating system 4100 are passed" via the device man- 
ager 4313 to the event manager 4273. M a preferred 
realisation, some prioritisatian of the received events 
may be carried out by the device manager 4313 and/or 
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the mujftask system used in the operating system 
41 00. However, as wffl become dear, one of the ^van- 
tages of the present system Ces in the fact that unlike 
the system deserted in PCT/EP97/021 16. the handling 
of eyentejs marag^ witfm the ytrt^.maddp.e 425P. 
ttiusenabpr^ creator tfterrtidiev^^ 
complete control cverthe eyejitftajitfi^ pjpeedura 
[00661 In the present errt»0jment events sent yiathe 
device manager 4313 are ciassfied by -thenr code and 
their type*. The code kfcsnjffies tfie chamctert^Scsoitne 
event for example, in the: case of an event generated 
through operation of a remote control associated with 
the decoder., the code can identify the button 
depressed. Hie type Wenffies the origin of the event 
ev&- the remote control. 

[00671 U»n receipt of an eventsignaL the wen* man- 
ager 4273 uses a routing table 4560 to de*ennfn& the 
event priority and thread destination and inserts a corre- 
sporting event object 4564 into one or more ftreads 
4561 located within the. priority based ftreap) queue 
4562. One or more event objects 4554 may be stored 
within a given thread as> represented at 4563. Tho event 
objects 4564 are stocted within the trtread according to 
their priority classification. Event objects within the 
thread of an equal priority are classified by their time of 
arrival (FIFO*. 

[0068] Lfeoo receipt of an event the event manager 
4273 signals its arrival to the scheduler 4270, which 
then examines the thread queue to see if a thread has a 
higher priority than the thread currently being executed. 
If so, the current thread is then suspended as described 
above and tie new thread executed. In this manner a 
pre-emptive thread handling system is irnplemented* 
[0069] In mis way. the preferred embodiment allows 
efficient handling of threads in the decoder so as to per- 
mit the system to respond quickly to event cafls, even In 
the case where the system is processing an existing 
prior event The disadvantages of the known single 
processor queue system are (hereby overcome. 
[00701 Whilst the preferred embodment has been 
described in relation to a pre-emptive system in which 
the arrival of an event causes the event manager to sig- 
nal the scheduler to interrupt execution of a thread, 
other frnptementatoons are possible. For example, in a 
time-slice system, the scheduler can periodrcafly inter- 
rupt execution of a thread to examine the state of the 
thread queue. Alternatively, the scheduler can be 
adapted to interrupt exec u tion of a thread to examine 
the thread queue after each instruction in that the 
thread as treated. 

MEMORY MANAGER 

[0071] As win be appreciated, in the context of 
recerver/decoder. the management of the memory pool 
within the system is particularly important since mem- 
ory space is relatively restricted as compared to for 
example, a PC or other hard cfiskbased platform. In the 
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following description, the memory, pool, corresponds to . . 
the rnempry. space, within the; RAM of the. 
receiver/arcades. However, as mentioned above, the 
oorresppndence between the physical and logical 

5 organisation of thp memory is not. exact arid the menv . 
ory pool described betaw rray. be.located-in or shared 
between other physical memory devices, such as a 
FLASH . memory, . an. EEPHDM etc, within the 
rece^/o^codei. . ..." .... ^ ,. v ... t _ s ^ 

to [00721 Refemri0,rtow to. Figure a this stows, the 
organisation of .the gvaflaWe memory in the system: ft 
wffl t*e seen, tha^t the memory .space is, shared between 
a pool ^ hand es 4600, a pool of qjsplaceab te objects 
461 a. and a pool of norKfepiaceeMe ctoiects4620,. 

is [00731 Each object in the pppJ 461? is identified by, 
and corresponds to a handle stored in the pool 4600. 
The rotation betnw$ei> a handle and its corresponding 
object is managec) vy the memory management pack- 
age 4^74 (see Figure 4} which also controls the access . 

do tothepppL call^ to object in the pc^ are made by 
its handle. The boundary between the pools 4600. and . 
4610 is movabla When a new object is lobe stored in 
memory a handle is created in the pool 45QP inducing* 
pointer to the address of the object within th e pool 4610. 

25 In such a case, the list of handles will be increased by 
one. The.hendies are organised in a fist formation in the 
pool to permit compactage by the memory manager. 
[0074] Objects will be allocated in the pool as needed 
and accottfing to the space available. In the case that an 

so object allocation is demanded which requires more 
space in one block *«n is available, it wiR be necessary 
to compact the objects already allocated in the memory. 
The compaction of the objects in the memory can be 
carried out according to any known compacting algor 

as rithm, for example, a copy-compact algorithm. In the - 
present embodiment, the Mark Sweep, compact algo- 
rithm is used. In order to compact space, the objects are 
moved around In the zone 4610, so as to group objects 
more closely together, avoiding any spaces between 

40 adjacent objects. In this way, afi free memory space is 
clustered together in a btock so as to allocate tore new 
object in the pool 4610. 

[0075] As mentioned above, the memory manage- 
ment package maintains the correspondence between 

4S handles in the pool 4600 and objects in the pool 4610 
and the new addresses of the objects in the pool wiO be 
updated into the equivalent handles for future access. 
[0076] Whilst the use of a handles to access certain 
objects enables the system to optimise memory location 

so in the pool, the process increases the time needed to 
access such objects, since it is always necessary to first 
retrieve the handle in order to look up the address of the 
object in certain situations and for objects correspond- 
ing to certain designated events a more rapid access 

ss time may be required. 

[0077] In such a case, the objects can be allocated in 
a pool of non-displaceable objects 4620. The address of 
such objects is fixed within the pool. There is thus no 
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need for the creation of a handle and the objects are 
used direcfiy by the system, thereby simpBfyrng the 
access procedure tar these special objects. Again, as 
with the boundary between the poote 4600 and 4610, 
the boundary between the pools 4620 and 461 0 wHl be 
shifted depending an the infcrmation stocked in the pool 
4620. 

[0070] In the event for example, that a m>rv<fisptace- 
able object is be allocated to the pool 4620 and there fe 
insufficient space due to the arrangement of displaces- 
b)e objects in the pool 4610, a compacfon of the dis- 
ptaceable objects may be carried out, as described 
above. Once the objects in the pool are reorganised so 
as to fiberate the maximum amount of space it may then 
be possible to allocate a rwtfrsptaceafcle block rn the 
pool 4620. 

{00791 The choice of which objects are displaceaWe 
and which objects are norKfispfacoable is at the discre- 
tion of the designer. For example, objects correspond- 
ing to the system may be chosen as noncfiqptaceaUe Hi 
view of the importance of these objects, whilst high teval 
appicafion objects may be dteplaceaWa. In certain 
instances. displaceaWe objects can be temporarily 
locked into place so as to be considered as non-mova- 
ble objects. 

[0080] In orderto eliminate unwanted objects from the 
memory poot the system may also include a so-called 
garbage collection. This Involves the creation of a spe- 
cial garbage collector thread of the lowest priority which 
wis be addressed by the scheduler fn the event that no 
other threads are currently stored in the queue. Upon 
execution, all cfeptaceabJe objects currently allocated in 
the pool that are not being referenced atthat time win be 
freed. The garbage collector thread may also carry out 
compaction of all other disptaceaMe objects along the 
lines described above. 

10091] The creation of a garbage conector fliread is 
known in the context of other muffittvead systems used 
in other applications outside of a digital television sys- 
tem and win not be discussed in any further detail here. 
However, it wiO be appreciated that use of a garbage 
collection procedure in combination with the other mem- 
ory management techniques described above provides 
particular advantages in the present context 
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pass such code to a corresponding interpreter 
means for interpretation and execution. 

An apparatus as claimed in claim 1 in which the vir- 
tual machine distinguishes between interpretative 
code in at least two interpretative languages based 
on the tfiaracterfetfcs of a h eader message associ- 
ated with a module of code rn one of the languages. 

An apparatus as darned in daim 1 or 2 in which the 
virtual machine distinguishes between interpreta- 
tive code based on the presence or absence of a 
header message associated with a module of code 
in one of the languages. 

An apparatus as claimed in any of claims 1 to 3 in 
which at least one of the languages is an object ori- 
ented languaga 

An apparatus as claimed in any preceding daim rn 
which the virtual machine identifies code written in 
an object oriented language by the presence of a 
header message associated with a dass file in that 
language* 

. An apparatus as claimed tn any preceding daim in 
which each Interpreter means executes code with 
reference to one or more function libraries* 

An apparatus as claimed in daim 6 in which a com- 
mon function library is shared by a plurality of the 
interpreter means. 

An apparatus as claimed in daim 6 or 7 in which 
one or more of the interpreter means executes 
code with reference to a function library exclusive to 
that interpreter means. 

An apparatus as claimed in any preceding daim in 
which the apparatus is a decoder for a digital televi- 
sion system 



1. An apparatus for processing digital audio-visual 
data comprtsrng one or more hardware devices for 
transmission and reception of data external of the so 
apparatus, the apparatus further comprising a data 
processing system including a first virtual machine 
adapted to, inter aGa, receive code written in an 
interpretative language downloaded via one or 
more of the hardware devices, said virtual machine ss 
being adapted to distinguish between code written 
in at least two interpretative languages Tn depend- 
ence on the structure of fr*e received code and to 



10, An apparatus as claimed in any preceding claim in 
which one of the devices comprises an MPEG 
demultiplexer. 

11. An apparatus as claimed in any preceding daim in 
which the hardware devices may comprise at least 
one of the following: a tuner, a serial interface, a 
parallel interface, a modem and one or more smart 
card readers. 
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